Greetings, friends!

When you rent a VPS and deploy a project on it, it might seem like the system is in complete silence until real users visit the site. But as soon as you open the raw system logs, the illusion of calm instantly shatters. In 2026, the internet turned into an aggressive environment where thousands of automated AI scanners and botnets probe every available IPv4 and IPv6 address around the clock looking for vulnerabilities.

Most successful hacker attacks happen not because cybercriminals use ultra-complex private exploits. Hackers simply find an open admin panel, a forgotten backup in a public folder, or guess a weak SSH password. The server always "screams" that it is being attacked, leaving hundreds of entries in the logs. The main thing is to know how to read these records. Speaking from personal experience, since I record video tutorials for our YouTube channel, I can say this: even if a server has been up for just a few minutes, bots are already probing it, and this is clearly visible as soon as you open the logs folder.

In this article, we will break down the main indicators of suspicious activity in Linux (Ubuntu 24.04 / Debian) and Nginx logs, and learn how to identify attackers before they cause real damage.

Key Takeaways: Main Points About Log Analysis

Logs are the system's black boxes: In case of any anomaly in server behavior, the audit must begin at two main points: /var/log/auth.log (OS security) and the web server access log.
Automation beats routine: Searching manually for signs of an intrusion across gigabytes of text files is inefficient. Use regular expressions and automation utilities (Fail2ban, Graylog).
Silence is a bad sign: If log files are exactly 0 bytes or abruptly cut off, it's a sure sign that an intruder has already established a foothold in the system and cleared all traces of their presence.

How to Install Fail2ban and Graylog?

We have recorded detailed video guides showing the step-by-step process of installing and configuring both automated defense and monitoring tools on your server.

Video Guide for Installing Fail2ban on Ubuntu:

You will find all the commands to configure the SSH jail and ban timeouts in the video description and the pinned comment.
Video Guide for Deploying the Graylog Log Collection System:

All configuration files, repository keys, and commands for data node integration are available in the video description.

Main Attack Indicators: What to Look for in the Logs?

1. SSH Brute Force (Password Guessing)

The authentication log is the first place botnets hit. Open the /var/log/auth.log file (on CentOS/RHEL, this is /var/log/secure). If you see endless lines like:

Plaintext

Failed password for invalid user admin from 192.0.2.5 port 43210 ssh2

This means that a dictionary attack is being executed against your server right now, cycling through popular logins (root, admin, user, test).

2. Hidden File and Admin Panel Probing (Web Scanning)

In the logs of an Nginx or Apache web server (/var/log/nginx/access.log), an attack looks like an avalanche of rapid requests returning a 404 Not Found status. Scanners look for vulnerable interfaces and configuration files:

GET /wp-admin/ or /wp-login.php (scanning for WordPress vulnerabilities)
GET /.env or GET /config.json (attempts to steal database passwords and API keys)
GET /.git/config (an attempt to download the project's repository)
GET /phpMyAdmin/index.php (searching for database management panels)

3. SQL Injections and Remote Code Execution (RCE)

If requests containing a lot of strange characters, quotes, or system paths appear in the web server logs, someone is targeting you intentionally:

GET /index.php?id=1+AND+(SELECT+321+FROM+(SELECT(SLEEP(5))) — checking for a blind SQL injection vulnerability.
GET /cgi-bin/main.cgi?cmd=cat%/etc/passwd — an attempt to read sensitive Linux system files without authorization.

Core Comparison Table: Types of Activity in Server Logs

Activity Type	Log Line Example	Attack Objective	Immediate Admin Action
SSH Brute Force	`Failed password for root from...`	Gaining full root access to the OS.	Change SSH port, disable root login, switch to SSH keys.
CMS Vulnerabilities	`GET /wp-content/plugins/... 200`	Injecting a web shell or a spam script.	Immediately update CMS core and all plugins.
Path Traversal	`GET /../../etc/passwd 400`	Reading configuration files and private data.	Properly configure `open_basedir` restrictions in PHP.
Port Scanning	Short TCP requests with zero data payload.	Mapping active services running on the server.	Close all unused ports using UFW/iptables.

Hands-on: 3 Commands for Quick Server Auditing via Console

To quickly assess the current situation on an Ubuntu 24.04 server, use these simple terminal commands. They aggregate text data into structured statistics:

Find the top 10 IP addresses brute-forcing your SSH:

Bash
sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head -n 10

Analyze the most frequent 404 errors in Nginx (identifying scanners):

Bash

sudo awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 10

Check for successful user account logins:

Bash

sudo grep "Accepted password\|Accepted publickey" /var/log/auth.log

FAQ: Quick Summary

My server logs show thousands of "Failed password" errors every day. Is it time to panic?
No, this is standard internet background noise. Automated bots scan all available IP addresses sequentially. As long as you have disabled password authentication for the root user and configured Fail2ban, these attempts are completely harmless to your server.
What should I do if I find a malicious hacker's IP address?
Block it at the firewall level. For example, using the UFW utility, this can be done with one short command: sudo ufw deny from IP_address.
How can I protect logs from being deleted by hackers?
If an attacker gains root privileges, they will wipe the log files. To prevent this, configure centralized log collection onto an isolated server (for example, using the Graylog system we mentioned earlier).

Conclusion

Regular log analysis is a fundamental skill that allows you to notice a hacker's interest in your project early and block the threat during the reconnaissance stage. Remember: system security is only as strong as its weakest link. Clean code, closed ports, and network log monitoring guarantee stable uptime.

Since deep packet analysis, real-time log parsing, and the operation of defensive systems (such as Fail2ban, Zeek, or Suricata) place a constant load on the disk subsystem and CPU, security demands a high-quality hardware foundation.

If you are currently looking for a reliable hosting solution for your projects, explore our NVME VPS / Dedicated Server services at MivoCloud.

Article Author — Anatolie Cohaniuc

Analyzing server logs: How do you know if someone is trying to hack you?